Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update Chinese & Cantonese localization #7235

Merged
merged 14 commits into from
Dec 31, 2024
Merged

Update Chinese & Cantonese localization #7235

merged 14 commits into from
Dec 31, 2024

Conversation

auroursa
Copy link
Contributor

@auroursa auroursa commented Dec 21, 2024 •
edited
Loading

This PR includes the latest translations from Crowdin, and cleans up outdated strings.

Update: We are attempting to convert the language codes for Chinese and Cantonese from RFC-1766 to RFC-4646, to resolve language-related compatibility issues on native.

The following are the changes:

  • zh-CN -> zh-Hans-CN
  • zh-TW -> zh-Hant-TW
  • zh-HK -> zh-Hant-HK

They are lengthy, but both Android and iOS are currently using them. and they are the recommended language code for Chinese by IANA and BCP 47. The tricky issue with Chinese at the moment is that there are two conflicting standards, both of which are widely used.

The compatibility issue on Android stems from the differences in Hermes implementation of Intl. On Android, it is based on the ICU4j project, which does not include RFC 1766 Chinese language codes like zh-CN since Android 7.0. This will be an attempt to fix #6728 without introducing polyfills.

Similar to #6774, tests have shown that zh-Hans-CN, zh-Hant-TW and zh-Hant-HK can also be correctly used by app language.

Since these code changes are all related to Chinese adjustments (including modifications to deviceLocales.ts), I’ve included them in the regular Chinese localization update PR instead of opening a new one. This also helps our translators test the impact of the changes earlier.

The related changes to deviceLocales.ts can refer to #6621, except this time the conversion is reversed: from RFC 1766 to RFC 4646, as browsers still widely use RFC 1766. We still need them to correctly match the browser’s default language, and display Chinese when opening the web for the first time.

As far as I know, most open-source cross-platform apps that support Chinese have similar mapping mechanisms.I believe this is currently the best approach I’ve come up with for balancing Chinese display across platforms after repeated testing and research.

Note the impact of changing the language code is limited to the app display language, Cantonese still cannot be used as post language.

Co-maintained by @cirx1e @hakadao @VentusUta

@auroursa
Copy link
Contributor Author

I have considered directly using zh-Hans and zh-Hant instead of the current more complex expressions, but in my cross-testing, their compatibility wasn't good.

@auroursa auroursa mentioned this pull request Dec 23, 2024
Closed
@auroursa
Copy link
Contributor Author

Over the past few months, I’ve been trying to understand why compatibility issues with Chinese keep occurring. Maybe this is unlikely to be implemented, but for Chinese, separating Web language code and Native App language code could greatly enhance the experience.

With the current code, I can only compromise on Web or Native. Previously I chose to compromise on Native, attempting to make iOS/Android match the Web language codes. Now I try to convert the Web language codes to match Native.

@auroursa
Copy link
Contributor Author

It looks good to me so far. Then will focus on the continuous improvement of the translation itself. Ready to go.

For reference the most suitable Chinese language tags for the platforms:

iOS: zh-Hans / zh-Hant
zh-Hans-CN can be recognized, but it require a strict match with the system language set to Simplified Chinese + region set to China Mainland, if the locale is set to Canada for example, it will no longer match (outputting something unusual like zh-Hans-CA). With a similar rule for Traditional Chinese, this is why we still need startsWith matching.

Android: zh-Hans-CN / zh-Hant-TW
It doesn't recognize zh-Hans at all, but uses zh-Hans-CN doesn't have the strict matching like iOS, this will also solve the post time localization issue. So we decided to convert all platforms to this.

Web: zh-CN / zh-TW
Almost all browsers have primitive support for RFC 4646 Chinese language tags. If the browser uses Simplified Chinese, it will still output zh-CN. This is why we need to map them after converting from RFC 1766 to RFC 4646. Edge briefly used zh-Hans as the default behavior during the EdgeHTML era, but after switching to the Blink engine, it reverted back to zh-CN.

Lastly, Merry Christmas and a Happy New Year!

pfrazee
pfrazee approved these changes Dec 31, 2024
View reviewed changes
Copy link
Collaborator

@pfrazee pfrazee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay! Thanks so much!

@pfrazee pfrazee merged commit cf1ccdf into bluesky-social:main Dec 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@pfrazee pfrazee pfrazee approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Post time in Chinese cannot be localized on Android
2 participants
@auroursa @pfrazee